|
Unlike traditional languages, the Universal Systems Language (USL) is a computer system language based on a preventive instead of a curative paradigm.〔M. Hamilton and W. R. Hackler, "(Universal Systems Language: Lessons Learned from Apollo )", IEEE Computer, Dec. 2008.〕 Based on systems theory, to a great extent derived from lessons learned from the Apollo onboard flight software effort, USL has evolved over several decades (originally called 001AXES) and taken on multiple dimensions as a systems engineering approach. USL is a completely different way to think about systems: instead of object-oriented and model-driven systems, the designer thinks in terms of system-oriented objects (SOOs) and system-driven models. Much of what seems counter-intuitive with traditional approaches, which tend to be software-centric, becomes intuitive with this systems-centric approach. USL was created by Margaret Hamilton for designing systems with significantly increased reliability, higher productivity, and lower risk. It was designed to achieve the following objectives: * reduce complexity and bring clarity into the thinking process; * ensure correctness by inherent, universal, built-in language properties; * ensure seamless integration from systems to software; * ensure traceability and evolvability, * develop unambiguous requirements, specifications, and design; * ensure that there are no interface errors in a system design and its derivatives; * maximize inherent reuse; * ensure that every model captures real-time execution semantics (for example, asynchronous and distributed); * establish automatic generation of much of design, reducing the need for designers’ involvement in implementation details; * establish automatic generation of 100 percent, fully production-ready code, from system specifications, for any kind or size of software application; and * eliminate the need for a high percentage of testing without compromising reliability. USL, together with its automation,〔(001 Tool Suite (1986-2015) )〕 can address these objectives because of the systems theory that forms its foundations. It also takes roots from other sources–other real-world systems and formal linguistics, methods, and object technologies. ==Apollo beginnings== USL had as its origin its creators' study of the Apollo program flight software development.〔 This study included the errors that took place during verification and validation of the Apollo software. The interface errors were analyzed in greater detail first, because they not only accounted for the majority of errors, they also were often the most subtle and most difficult to find. Each interface error was placed into a category identifying the means to prevent it by way of system definition. This process led to a set of six axioms, forming the basis for a new mathematical theory for designing systems that would, among other things, eliminate the entire class of interface errors just by the way a system is defined. Given the ongoing evaluation of the Apollo effort, it became clear that a new kind of language was needed and that this mathematical theory could provide its core. Results of the analysis took on many dimensions, not just for space missions but for applications in general, and not just for software but systems in general–the results of which were not readily apparent for many years to come. Lessons learned from this effort continue today: Systems are asynchronous, distributed, and event-driven in nature, and this should be reflected inherently in the language used to define them and the tools used to build them. This implies that a system’s definition should characterize natural behavior in terms of real-time execution semantics, and designers should no longer need to explicitly define schedules of when events are to occur. Instead, events should occur when objects interact with other objects so that by defining such interactions the schedule of events is inherently defined. Most importantly, it became clear that the root problem with traditional approaches is that they support users in “fixing wrong things up” rather than in “doing things in the right way in the first place”. Combined with further research, as this became more widely understood, it became clear that the characteristics of good design could be reused by incorporating them into a language for defining systems. USL captures the lessons learned from Apollo. When a model is defined with USL, correctness is accomplished by the very way a system is defined, by built-in language properties inherent in the grammar. Whereas the traditional software development approach is curative, testing for errors late into the life cycle, USL’s development-before-the-fact philosophy is preventive, not allowing errors in the first place. A USL definition models both its application (for example, an avionics or banking system) and properties of control into its own life cycle.〔Dolha, Steve, Chiste, Dave, "A Remote Query System for the Web: Managing the Development of Distributed Systems.", Chapter 32, Internet Management, Editor Jessica Keyes, Auerbach, 2000.〕 Each SOO definition has built-in constraints that support the designer and developer, yet they do not take away flexibility in fulfilling requirements. A SOO inherently integrates all aspects of a system (for example, function-, object-, and timing-oriented). Every system is an object, every object a system. Mathematical approaches are known to be difficult to understand and are limited in their use for nontrivial systems as well as for much of the system’s life cycle. Unlike formal languages that are not friendly or practical, and friendly or practical languages that are not formal, its users consider USL to be not only formal but also practical and friendly.〔Middleton, Frank, "USL For Fun and Profit", The IEEE Newsletter May 2009, IEEE North Jersey Section Computer Society Chapter, May 19, 2009.〕〔Krut, Jr., B., “(Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology )” (CMU/SEI-93-TR-11, ESC-TR-93-188), Pittsburgh, SEI, Carnegie Mellon University, 1993.〕 Unlike other mathematically based formal methods, USL extends traditional mathematics with a unique concept of control: universal real-world properties internal to its grammar–such as those related to time and space–are inherent, enabling USL to support the definition and realization of any kind or size of system. The formalism along with its unfriendliness is “hidden” by language mechanisms derived in terms of that formalism. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Universal Systems Language」の詳細全文を読む スポンサード リンク
|